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Abstract. Event-B is a formal approach oriented to system modeling 
and analysis. It supports refinement mechanism that enables stepwise 
modeling and verification of a system. By using refinement, the complex- 
ity of verification can be spread and mitigated. In common development 
using Event-B, a specification written in a natural language is examined 
before modeling in order to plan the modeling and refinement strat- 
egy. After that, starting from a simple abstract model, concrete models 
in several different abstraction levels are constructed by gradually in- 
troducing complex structures and concepts. Although users of Event-B 
have to plan how to abstract the specification for the construction of 
each model, guidelines for such a planning have not been suggested. 
Specifically, some elements in a model often require that other elements 
are included in the model because of semantics constraints of Event-B. 
As such requirements introduces many elements at once, non-experts of 
Event-B often make refinement rough though rough refinement does not 
mitigate the complexity of verification well. In response to the problem, a 
method is proposed to plan what models are constructed in each abstrac- 
tion level. The method calculates plans that mitigate the complexity well 
considering the semantics constraints of Event-B and the relationships 
between elements in a system. 
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straction 



1 Introduction 

Event-B [2] is a formal approach oriented to system-level analysis and modeling. 
Event-B users specify models in a notation based on set theory and first order 
logic and check the model by proving. 

The most notable feature of Event-B is the support for refinement mech- 
anism. In a refinement process, users first construct a simple and highly ab- 
stract model. After checking the consistency in the abstract model, more com- 
plex model is constructed and the consistency between the abstract model and 
the complex model is checked. Usually complex models are constructed by in- 
troducing new aspects and properties of a system. Users gradually construct 



concrete models by repeating this step. Refinement enables users to construct 
a complex model more simply rather than to construct the complex model at 
once. Therefore, the burden of a model construction is mitigated by Event-B. 

As Event-B is an effective method, it has been attracting more and more at- 
tentions from the industry. For example, many companies in Japan are interested 
in formal methods including Event-B, while technical and administrative guide- 
lines are constructed through cooperation of a national institute and software 
vendors [1]. 

Refinement enables users to spread the complexity of modeling over some 
steps. However, it is necessary to properly define how elements are gradually in- 
troduced, mitigating the complexity while complying with semantics constraints 
of Event-B. In this paper, we propose a method that considers the constraints 
and relationships between elements of a system and plans what models should 
be constructed for an effective refinement. Thus the method enables ordinary 
users to leverage the refinement mechanism in a simple way. 

The remainder of this paper is organized as follows. Section [5] describes the 
problem and the cause of the problem. Section [3] describes the proposed method 
together with exemplification on an example. Section 2] shows related work as 
well as future work, before concluding remarks in Section [5] 

2 Problem and Approach 

In usual modeling in Event-B, users first read the specification of the system 
written in a natural language. Then models in several abstraction levels are 
constructed gradually. Event-B supports checking constructed models but does 
not guide modeling explicitly. Thus users have to plan what models are con- 
structed in each abstraction level. Specification of a system is composed of a set 
of statements about property of the system. We call such statements artifacts. 
For example, a specification of a library management system may include an ar- 
tifact "There are no loaned books in the open stack." . Usually, Event-B models 
include invariants that correspond to a subset of artifacts of the system. Thus, 
users have to plan which subset of artifacts of the system should be reflected 
to models of each abstraction level. When constructing a concrete model, new 
artifacts are added to artifacts of the abstract model. Therefore users need to 
plan which artifacts are introduced to each abstraction level. 

In Event-B models, artifacts are expressed as invariants using the formal 
language of Event-B. Thus, in order to express an artifact, it is necessary to 
introduce elements (e.g. career sets, constants, variables, and events) that cor- 
respond to terms appeared in the artifact. We call such terms phenomena. For 
instance, an artifact "There are no loaned books in the open stack." can be 
expressed like "openstack n dom{loan_state) = 0" (Where openstack C books 
and loanstate G hooks members) only when openstack and loan^state are 
already introduced to the model. 

Such constraints on the introduction of phenomena exist not only between an 
artifact and phenomena but also between a phenomenon and phenomena. That 



is, in some cases, an introduction of a phenomenon requires an introduction of 
some other phenomena. The causes of such constraints on introduction include 
the following two facts. 

Firstly, all variables and constants in an Event-B model have to be typed as a 
primitive type (a built-in data type or an element of a career set as a user-defined 
type) or a pair that is recursively built from primitive types. A primitive type 
is atomic and not expressible by using other primitive types. For example, if a 
variable var is typed as S by using a career set S in an abstract model and typed 
as T N by using a career set T and a built-in data type N in a concrete model, a 
type error will occur. Thus, any typing statement of a phenomenon should not be 
changed through refinement. Therefore, a phenomenon corresponds to a variable 
or a constant can be introduced only when phenomena that are necessary to 
type the variable or constant are already introduced. For instance, in order 
to introduce a phenomenon "loan state" and express its type as loanstate G 
books ^ members, the introduction of career sets books and members is needed. 
Thus, it is also required to introduce phenomena that corresponds to career sets 
books and members. 

Secondly, Event-B has several criteria for consistency between an abstract 
model and a concrete model. In modeling in Event-B, users can confirm consis- 
tency of models by proving them (proof obligations). There is a proof obligation 
named EQL, which requires that if a variable is included in both an abstract 
model and a concrete model there must not be a state transition such that it is 
included in the concrete model but not included in the abstract model. In order 
to make a refinement consistent EQL proof obligation must hold. Therefore a 
phenomenon corresponds to a variable can be introduced in a model only when 
state transitions that change the value of the variable are already introduced. 
For example, the introduction of a variable that corresponds to a phenomenon 
"loan state" requires an introduction of all state transitions included in the be- 
havior of the system (e.g. "loaning a book from the open stack", "returning a 
book" , "loaning a reserved book" ) . 

For these reasons, an introduction of an artifact to a model requires intro- 
ductions of 1) phenomena that appear in the artifact and 2) phenomena that 
are required by 1). Let A = (^i)i=o,i.- - (^o = 0) be a sequence of sets of ar- 
tifacts reflected to the nth model, req_a(o) be the phenomena required by an 
introduction of an artifact a, and req_as(Ai) = UaeA i'eq_a(a) for a set of ar- 
tifacts Ai. When an artifact is introduced, phenomena that are not introduced 
yet but required for an introduction of the artifact are also introduced. Then, 
let int_Pj(yl) — req_as(Ai) \ req_as(ylj_i) (1 < It denotes newly installed 
phenomena to the ith model in a sequence of artifacts sets (Ai)i=o,i,- - • 

Consider the introduction order of artifacts a and b such that req_a(a) — 
{pi,-- - ,_pio}, req_a(&) — {pe, • • • iPi(),q} to an empty model (Figured]). For 
Ai = {a},A2 = {a,b}, the newly introduced phenomena will be as follows: 
int_Pi(A) = req_a(a) = {pi,--- ,Pio}, int_p2(A) = req_a(&) \ req_a(a) = {q}. 
In contrast. For Bi = {b},B2 = {a,b}, the newly introduced phenomena will 



^ In this paper, the relative complement of a set T in a set S is denoted by S \ T. 



be as follows: mtjpi{B) = req_a(6) = {pe,- 
req_a(6) = {pi,--- ,^5}. 



,Pio,q}, int_p2(B) = req_a(a) \ 



req_as({a}) 




Fig. 1. Difference between Two Introduction Orders 

Therefore, (|int_pi(^)|, |int_p2(A)|) = (10,1), whereas (|int_pi(B)|, 
|int_p2(i?)|) — (6, 5). Thus, the number of newly introduced phenomena in each 
model will vary depending on the introduction order of artifacts. As refinement 
is a mechanism to mitigate the complexity of modeling by spreading the intro- 
duction of phenomena over some steps, how much the numbers of newly intro- 
duced phenomena are dispersed is useful information for users to plan refinement. 
Thus, we define the effectiveness of an introduction order of artifacts as in Def- 
inition [TJ For instance, the order (a, 6) is more effective than {b,a) in the above 
example. Moreover, an order (Ai)i=o.- - ,3 such that (num a, i) 1=1,2.3 = (3,1,2) 
is more effective than an order (i?i)i=o,- - ,3 such that {numB,i)i= 1,2. 3 — (0,3,3) 
since {snumA,i)i=i,2,3 = (3,2,1) is smaller than {snumB,i)i= 1,2, 3 — (3,3,0) in 
lexicographical order. 

Definition 1. Let a sequence {numA,i)i=i.... ,\a\ ^ history of the number of 
phenomena newly introduced in each refinement (i.e. numA,i = |int_Pj(A)[^ and 
a sequence {snumA.i)i=i.... .\a\ be a sorted permutation of {numA,i)i=i,--- ,\a\ 
descending order. Then, for a sequence (^i)i=o,--- and (i?j)'i=o.--- such 
that req_as(A|^|) — req_as(i?|s|); (^i)i=o.--- called more effective than 
(5i)i=o,--- if isnumA,i)i=i,... ,\A\ is smaller than {snumB,i)i=i,... ,\b\ in lexi- 
cographical order. 

As in the above example, users should plan an introduction order of artifacts so 
that the refinement is effective. However, for this planning, users have to grasp 
and compare the constraints on introduction between phenomena over multi- 



Table 1. Artifacts of Library Management System 



Artifact Phenomena Appeared in the Artifact 

a "Loan is done only for members" loan state, members 

b "Books on loan are not in the open stack" loan state, books, open stack state 
c "No reserved books are in the open stack" reservation state, books, open stack state 



Table 2. Events of Library Management System 

Event Caused State Transitions 

pi Loaning a reserved books Remove one from reservation state, 

Add one to loan state 
p2 Returning a book Remove one from loan state 

p3 Loaning a book from the open stack Remove one from open stack state. 

Add one to loan state 



pie steps. The constraints are too complex for users to analyze in their heads. 
Therefore, Event-B users (especially beginners) have to repeat trial and error 
processes during modeling many times. Thus, though refinement is a powerful 
mechanism, it is not so easy to use refinement in realistic situations. 

3 Method 

3.1 Derivation of Required Phenomena 

As we viewed in Section [2j the effectiveness of refinement depends on the sets of 
phenomena required by artifacts. The phenomena required by an artifact depend 
on types and state transitions related to phenomena that appear in the artifact. 
In the proposed method, constraints on introduction between phenomena related 
to types and state transitions are assumed as the input. The output of the 
method is orders that maximize the effectiveness of refinement. 

To illustrate the method, construction of a model of a library management 
system is described. The artifacts of the system are as shown in Tabic [1] and the 
events of the system are as shown in Table [2] Events represent behavior of the 
system. An event can cause multiple state transitions. 

Phenomena can be classified into four kinds according to what kind of element 
in an Event-B model corresponds to the phenomenon. Phenomenon corresponds 
to a career set, a constant, a variable, or an event. 

Let Psj -Pc, -fV) and Pe be the set of phenomena that correspond to career 
sets, constants, variables, and events, respectively. Let P = Ps U Pc U Py U Pe 
and T be the set of state transitions. 

Let typed : P — >■ 2^^ be a set of career sets required for typing a constant or 
a variable, changed-by : P ^ 2'^ be a set of state transitions that change the 
value of a variable, and causedJjy : T — > 2^"=^ be a set of events that causes a 
state transition. 




Fig. 2. Constraints on Introduction between Piienomena in Library Management Sys- 
tem 



The proposed method takes these three functions as the input from the users. 
For example, constraints on introduction between phenomena in the hbrary man- 
agement system can be depicted as in Figure [2J 

The set of career sets required for typing a phenomenon can be derived by 
tracing typed edges. The set of events that change a phenomenon can be derived 
by tracing changedJjy edges and causedJjy edges. Therefore, let req_p(p) be the 
phenomena required by an introduction of a phenomenon p, then req_p(p) can 
be derived by the input. That is, 

req_p(p) = typed{p) U causedJ)y(t) . (1) 

t^changedjiy (p) 

Thus, req_a(a) can be derived by the input. That is, 

req_a(a) = appear(a) U req_p(p) . (2) 

pGappcar(a) 

Where appear(a) denotes the phenomena that directly appear in an artifact a. 
By constraints on introduction depicted in Figure Hand Equations © and (l2|), 
req_a of each artifact in the library management system is derived as follows: 

req_a(a) ^ { pi, p2, p3, p5, p7, p8 } 
req_a(6) = { pi, p2, p3, p5, p6, p7, p8 } 
req_a(c) = { pi, p3, p4, p6, p7, p8 } 



Table 3. All Introduction Order of Artifacts in Library Management System 



(int_ai(^))i=i,2,3 (|int_Pj(>l)|)i=i,2,3 Effectiveness Rank 



(W,W,W) 


(6,1,1) 


1 


(W,H,W) 


(6,2,0) 


2 


({c},W,W) 


(6,2,0) 


2 


({c},W,W) 


(6,2,0) 


2 


(W,W,W) 


(7,0,1) 


3 


(W,W,W) 


(7,1,0) 


3 



3.2 Search for the Best Introduction Orders of Artifacts 



Let int_ai(A) = Ai \ Ai^i (1 < i). It denotes newly introduced artifacts to 
the ith model. We assume that only one artifact is introduced through one 
refinement step. Then, |int_ai(A)l = 1 (1 < i) and req_as(Ai) — req_a(a) U 
req_as(Ai_i) (1 < i) where a = |int_a.i(A)|. 

In the proposed method, orders that correspond to sequences (^j)i=o.- - ,|A| 
that maximized the effectiveness of the refinement are obtained by Algorithm [TJ 
All orders of artifacts introduction ((int_ai(A))i=i.2,3) and the numbers of newly 
introduced phenomena ((|int_Pj(A) 1)^=1^2,3) in each refinement for the library 
management system is as shown in Table |31 In this case, the result of the algo- 
rithm represents the order ({a}, {&}, {c}). 

The method uses breadth first search with pruning as shown in the Algo- 
rithm [T] A node of the search tree represents an introduction order of artifacts. 
A structure that represents a node is composed of as that represents the history 
of artifacts introduction, ps that represents the set of phenomena introduced so 
far, nums that represents the history of the number of introduced phenomena in 
each step, max that represents the maximum of nums, and rest that represents 
the number of phenomena not introduced yet. 

The function CertainlyBetter (LinefT HTO)) checks whether an introduction 
order of artifacts is certainly effective than the other order. This function is 
used for pruning (Line [321 [23 • The number of phenomena introduced in a later 
refinement is at most the number of phenomena not introduced yet 
(maybeJbetter.rest) since req_as(Ai) C req_as(A|yi|) for all i. Therefore, an order 
is certainly better if the maximum number of introduced phenomena in each 
step of the order is at most less than the current maximum of the other order 
(Line[5HB]). If both maximums are equal, the algorithm retries the checking on 
orders without the artifact corresponds to the maximum number (Line ITHlSp . 



Algorithm 1 Search the Best Introduction Orders of Artifacts 



1: function CERTAINLYBETTER(maj/6e abetter, maybe^worse) 

2: if {{maybeJietter.nums = {}) V {maybejworse.nums = {})) then 

3: return false > Not sure whether maybeJ>etter is better 

4: else if {max{{maybej)('tter .max, maybe-better. rest}) < 

5: maybejjuorse.max) then 

6: return true > maybeJ)etter is certainly better 

7: else if maybe J^etter. max = maybejworse.max then 
8: new mbjreduced, mw -reduced 

9: mbjreduced.nums ^ maybe Jbetter.nums \ {maybejbetter.max} 

10: mwjr educed. nums maybe-worse.nurns \ {maybc-worse.max} 

11: mb -reduced. max max{mbjreduced.nums) 

12: mw -reduced. max <— max{mwjreduced.nums) 

13: mb-reduced.rest maybe Jietter. rest 

14: mw -reduced. rest <— maybc-worse.rest 

15: return CERTAiNLYBETTER(m6_reciwced, mw-reduced) 

16: else 

17: return /oZse > Not sure whether maybeJ)etter is better 

18: end if 
19: end function 

20: function SEARCHBESTORDER(ortt/ocis, req_as, n_art«/, n_p/ien) 

21: orders {{as : {}, ps : 0, nums : {}, max : 0, rest : njphen}} 

22: repeat 

23: for all order £ orders s.t. length{order.as) is minimum do 

24: orders orders \ {order} 

25: for all o £ {artifacts \ order.as) do 

26: new neworder 

27: neworder. as <— append{order.as,{a}) 

28: neworder.ps <— Teq-as{neworder.as) 

29: neworder. nums append{order.nums, {\neworder.ps \ order.ps\}) 

30: neworder.max max{neworder.nums) 

31: neworder .rest <— n-phen — sum{new order. nums) 

32: if not (3o £ orders s.t. CertainlyBetter(o, neworder)) then 

33: orders orders U {neworder} 

34: for all o 6 orders do 

35: if CERTAiNLYBETTER(neworder, o) then 

36: orders orders \ {o} 

37: end if 

38: end for 

39: end if 

40: end for 

41: end for 

42: until Vo € orders . length{o.as) = n-artif 

43: return orders 
44: end function 



4 Discussion 



4.1 Related Work 

There are some studies on requirement engineering methods for modehng in 
Event-B. In Problem Frames and Event-B are apphed successfuUy on an 
industrial project. The authors constructed a problem diagram before modeling 
in Event-B. They associated elaborations of phenomena in problem diagram with 
a data refinement in Event-B. The work of 5 proposed an iterative process of 
requirement modeling and validation. The authors connected reasoning about 
artifacts with refinement in Event-B. In |13j . Event-B specifications are derived 
from class and state-machine diagrams. However, refinement strategy planning 
is not covered in these studies. 

There have been many studies which aim at deriving formal specification in 
other methods than Event-B from natural language specifications or diagrams 
like UML [3 l [4 l[ 6H8 l[T0lfT2l [T4 l [T5] but refinement is not considered in these studies 
either. 

The authors of [11 proposed a method to derive an abstract specification of 
an event. In this study, patterns of correspondences between a KAOS goal model 
and an event in Event-B are provided. The patterns also consider a part of proof 
obligations that will be generated. From the point of view of refinement strategy 
planning, this method transforms a refinement strategy planning for an event 
into a refinement strategy planning in a KAOS goal model. On the other hand, 
our method plans refinement strategy of the whole model by considering the 
constraints on introduction between elements in the system. Thus our approach 
can be considered as complementary to this work. 

4.2 Future Work 

Further refinement of the proposed method is the primary part of the future 
work. 

First, we assumed every artifact is not changed through refinement. How- 
ever, that is not the case in realistic situations. There are many cases that some 
artifacts are strengthened in concrete models by using newly introduced phe- 
nomena. 

Refinement of events is also neglected. In realistic situations, many events 
are refined through refinements. For example, both event "Loaning a reserved 
books" and "Loaning a book from the open stack" can refine an event that only 
includes "Add one to loan state" state transition. 

Moreover, as we viewed in Section [51 we assumed that the complexity of 
modeling can be measured only by the number of phenomena. However this 
criterion is too rough. For instance, the importance of the number of events and 
that of variables are different. Thus, finer analysis of complexity of modeling is 
needed. 



5 Conclusion 



This paper has aimed at resolving complexities in planning of refinement strategy 
by considering semantics constraints of Event-B. Refinement strategy planning 
is an important and difficult phase in modeling in Event-B. Therefore, the pro- 
posed method facilitates ordinary users to leverage Event-B. Although much 
work remains as discussed in Section [4.21 we believe this work promotes system- 
atic use of formal specifications, more independently from specific knowledge 
and skills. 
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